Add extend login / logout via OAuth browser sign-in - #31

Replace the bare callback page with an Extend-styled card: inline
logomark SVG (derived from the terminal logo geometry), embedded CSS,
system fonts, no network fetches. Distinct copy for success, a
user-denied consent (access_denied), and error variants, with the
server-supplied error description HTML-escaped.

After the token exchange, call GET /me with the fresh access token and
print "Signed in to <workspace> (<Production|Test>) as <email>." built
from the resolved workspace, its granted environment, and the user
email. Best-effort: any /me failure keeps the generic "Logged in to
<base>." line and never fails the login (tokens are already stored).

RFC 8414 metadata was trusted wholesale: a redirected or poisoned
well-known document could advertise a foreign token endpoint and
receive the authorization code plus PKCE verifier. Every endpoint in a
successfully fetched document must now be on the API base URL's exact
host, over https (or the base's own scheme, which permits http only
for local dev bases that are themselves http); anything else fails the
login with an explicit rejection instead of falling back. Fetch
failures still fall back to the /oauth2/* defaults as before.

…ections

Two refresh-path fixes. First, the rotated token pair is now persisted
before the new access token is handed out, with one retry; if both
attempts fail, the source keeps working in memory (the rotation
already happened server-side, so failing would strand the user harder)
but warns loudly that a re-login may be needed instead of silently
continuing or erroring with the pair trapped in RAM.

Second, only a 400/401 carrying invalid_grant or invalid_client maps
to ReauthError. Previously any 4xx did, so a 429 or 408 from the token
endpoint told the user their login had expired; those (and 5xx,
timeouts, network errors) now surface as plain retryable refresh
failures that never clear or condemn the stored session.

The refresh single-flight was in-process only: two concurrent extend
invocations each redeem the same rotate-on-use refresh token, and the
loser trips the server's reuse detection, revoking the whole grant
family. Refresh now takes a cross-process lock (an O_CREATE|O_EXCL
lock file beside the fallback token store, with a stale-lock takeover
for crashed holders) and, once acquired, re-reads the store: if
another process already rotated the pair, its result is adopted
without a second grant. Lock-machinery failures other than
cancellation degrade to the in-process mutex rather than blocking
refresh.

The workspace name and email from GET /me were printed to the terminal
raw. Both are attacker-influenced (workspace names are user-set), so
embedded ANSI CSI or OSC sequences could restyle the terminal or spoof
output. Escape sequences are now stripped whole (including payloads),
along with C0 controls, DEL, and the raw C1 range, before the values
reach the success line.

- Token file writes fsync before the atomic rename so a crash cannot
  install a truncated file over the previous tokens.
- Token file reads refuse to follow a symlinked oauth_tokens.json.
- Token/revoke error bodies are capped at 64KB instead of 1MB.
- The SDK token func now runs under the command's signal-aware
  context (plumbed via extendx.Config.TokenContext) instead of
  context.Background(), so Ctrl-C aborts an in-flight refresh; the
  SDK's WithTokenFunc signature takes no per-request context, so the
  command context is the closest available scope.

The default http.Client follows 307/308 redirects by replaying the
request body, which on these calls carries the authorization code and
PKCE verifier, a live refresh token, or the token being revoked. Give
the discovery, exchange, refresh, and revoke clients a CheckRedirect
that rejects any hop whose origin (scheme + host + port) differs from
the configured API base, re-validating every hop of a chain.

Refreshing without the lock lets two CLI processes redeem the same
rotate-on-use refresh token, tripping the server's reuse detection and
revoking the whole family. Lock path or acquisition failures now fail
the refresh (with a bounded wait for a held lock) instead of degrading
to the in-process mutex alone. The lock also moves to a stable per-user
path keyed by the normalized API base, so processes launched with
different XDG_CONFIG_HOME still contend on the same lock while logins
against different bases no longer serialize each other.

The general SDK client had no redirect policy: Go's client copies the
Authorization header to same-registrable-host redirect targets, and
the OAuth bearer transport re-attaches a fresh access token on every
hop, so a 302 off the API origin (open redirect, compromised endpoint,
misconfigured CDN) would hand the live bearer to whatever host the
Location header names. Reuse the OAuth clients' CheckRedirect (now
exported) to pin every hop to the configured base URL, falling back to
the SDK's production default when none is set.

The upload client swapped in by UploadOption carries the same header
but has no view of the configured base, so it refuses redirects
outright; the eval runner's judge client gets the same origin pin for
its Anthropic key, which Go does not strip on cross-host redirects.

Nothing forced https for a remote base URL: pointing EXTEND_BASE_URL
(or the config file) at http://some.host ran the whole OAuth handshake
— PKCE verifier, authorization code, access and refresh tokens — and
every bearer-authenticated API call in cleartext. ValidateBaseURL now
refuses http bases unless the host is loopback (localhost, 127.0.0.0/8,
::1), where local dev servers live and traffic never leaves the
machine. Enforced where the base is resolved — effectiveBaseURL for
login/logout/refresh, the client closure and extendx.NewClient for API
commands — so every consumer inherits the check.

The /me sanitizer stripped escape sequences from the login success
line, but every other server-derived string on an error path was
printed verbatim: token endpoint error/error_description fields (also
raw proxy error bodies), the authorize redirect's error parameters
relayed by the loopback callback, and API error code/message/request-id
fields. A malicious or compromised endpoint could smuggle ANSI CSI/OSC
sequences through any of them to rewrite the terminal, hide text, or
set the window title.

Move the sanitizer to iostreams.SanitizeForTerminal and apply it at
construction — parseTokenError, the loopback callback handler, and
AsAPIError — so every formatting path (the CLI error printer as well
as %v/%w chains through Error()) inherits it. Discovery errors already
render endpoint values with %q, which escapes control bytes.

UX:
- Re-login now best-effort revokes the grant it replaces, so repeated
  logins no longer accumulate live orphaned grant families server-side.
- The success line always says "Signed in" and names non-region bases
  ("... on https://api.staging.extend.ai"): the environment
  parenthetical alone read as the production deployment when signed in
  to staging or a rig.
- New `extend whoami` prints the workspace, environment, user, auth
  method, and base URL for whichever credential is in effect (API key
  or stored login) via GET /me, which accepts both.
- `extend setup` ends with a tip pointing at `extend login`.
- Ctrl-C now renders "Canceled." instead of a raw "context canceled".
- README and the auth topic note that macOS may re-prompt for keychain
  access after a binary upgrade.

Hardening/polish:
- A token response without expires_in gets a floor lifetime instead of
  an already-expired token that would refresh on every command.
- Falling back from the keychain to the token file warns once per
  process; a keychain delete that provably left a record behind now
  fails logout instead of letting the login resurrect.
- A corrupted token store surfaces its read error in the
  "not logged in" message instead of masquerading as missing auth.
- TokenSource's persist-failure warning is routed through the command's
  IO streams (exported Warn) rather than a hardcoded stderr.
- A success callback landing after a failed one renders a failure page
  instead of "Already signed in".

The skill now installs as extend-cli (~/.agents/skills/extend-cli/,
name: extend-cli) instead of claiming the bare "extend" name — Extend
has other agent surfaces (the MCP server) that would contend for it.
Eval harnesses and tests follow the new path.

The skill's Authentication section catches up with the OAuth login:
it leads with `extend whoami`, presents both credential sources (API
key for scripts/CI/agents, browser login for interactive use), states
the precedence, and tells agents to ask the user rather than invent a
key. The pagination example's --max claim is now test-guarded too.

The README's Authenticate section is restructured by use case —
`extend login` for your own machine, API keys for scripts/CI/agents —
with the precedence rules in their own subsection, and the skill
section documents the extend-cli scoping plus a project-local install
target.

Setup is now a two-line choice (browser login or the API-key wizard);
Authentication contrasts the two credential types and lists precedence
as a numbered list. The OAuth flow mechanics, keychain re-prompt note,
and skill-naming rationale move out of the README — token storage
details stay available via 'extend help auth', which the README now
points at.

The wizard's first step now asks how to sign in. The browser path picks
a region, offers the skill install, then runs the same flow as 'extend
login' after the TUI exits — persisting the region and dropping any
saved API key first, since a resolved key always shadows a stored login
(an environment key gets a warning for the same reason). The API-key
path is unchanged, and the post-setup login tip is gone now that the
wizard itself offers the choice. Esc on the region step goes back to
the method chooser.